Inbound Integration to Kore Commerce

Kore Commerce has a series of inbound APIs which can be used to feed data into its SQL database. The following diagram shows a high-level example of the inbound integration model.

The integration layer (Kourier Export Service) is responsible for pushing this data out on a regular basis and sending it to an Inbox via FTP or network file access. Once data is delivered, Kore Commerce automatically loads the data into its SQL database and reports/Emails any exceptions. Both Kourier and Kore Commerce support a FULL or NET-Change refresh mode. The NET-Change (incremental) refresh mode leverages Kourier’s net change tracking so that the ERP database and the Kore Commerce SQL database are synchronized in near-real-time.

The standard format for inbound files is a tab-delimited file and it must comply with the corresponding API specification. The name of the file is important as it indicates to Kore Commerce how to process the file. The naming convention for the inbound files is as follows:

{source}_{sequence}_{integration}_{API}.{mode}

Where:

source = Where the file came from.

sequence = A seven digit, 0 filled number that ensures that files are processed in the correct sequence.

Kourier performs this function automatically to ensure files are processed in the correct sequence.

integration = The Integration ID in Kourier.

API = The name of the API specification to which the file corresponds.

mode = Denotes either a FULL or NET change refresh mode. Net Change refers to new and changed files. Full refresh processes all files.

Performing a full refresh is time consuming and requires a large amount of processing power. Be sure to only perform a full refresh after hours.

Following is an example file name.

DT_000001_KS_ORDERS.NET

In addition to the naming convention described above, each of the APIs must be sent based on an order of precedence because the Kore Commerce database maintains referential integrity. For example, the KS_CUSTOMERS API takes precedence over the KS_ORDERS API because orders refer to customers. This requires KS_CUSTOMERS to be sent first to preserve referential integrity and prevent database errors. The precedence level is defined in a table in the next section.